Let's gooooo! Thank you i will test this and try and pull it in soon

I just casually whipped up a table：
https://www.myvibe.so/zhangfan/sherpa-onnx-asr-models

Closing to recreate from a dedicated feature branch (this PR's head was fork/main which now contains unrelated changes).

Okay, when I'm looking at this, it's becoming increasingly obvious we need to significantly modify the codebase. I am going to do this, and then let's get these in. If you don't mind waiting and rebasing on top of this, it would be great.

Basically I want to separate things out into engines

• whisper.cpp
• whisperfile
• onnx
• mlx?
• ggml?

or similar, so we can then implement models per engine as well. i think this will be a much better way forward, but will require some better documentation. I think we can get something going like auto model porting as well from a given base implementation (usually hf transformers). We can potentially try and support the transformers implementations too, but largely I'm not super focused on that for the moment.

Before discovering your project, I actually used the sherpa-rs-sys crate, which worked exceptionally well. It not only supported streaming transcription but also allowed the integration of a wider range of models. The only drawback was the third-party code signing issue we encountered during project installation—this arose because we utilized third-party dynamic libraries in the project.

You may want to try out the forked branch I built based on your 0.6.8 version:

• I initially added support for cloud-based speech models due to the low hardware specifications of my device at the time.
• Later on, I further implemented streaming models for real-time transcription.
• Additional features include a demo showcase, transcription history analysis, and more.
• I also fully refactored the UI/UX of the application.

I originally intended to submit a PR for these changes, but ultimately abandoned the idea due to the extensive scope of the modifications.

You can check out this branch here: https://github.com/zhuzhuyule/Votype/tree/votype

Okay, when I'm looking at this, it's becoming increasingly obvious we need to significantly modify the codebase. I am going to do this, and then let's get these in. If you don't mind waiting and rebasing on top of this, it would be great.

Basically I want to separate things out into engines

• whisper.cpp
• whisperfile
  ...

Thanks for the plan! I totally support the idea of separating engines — it makes the architecture much cleaner.

One thing I'd like to share:I chose sherpa-onnx specifically because it already supports a huge variety of languages and models (100+ languages with Paraformer/Zipformer). While it may not match the quality of the latest SOTA models, it's practically "good enough" for most use cases and covers far more languages than whisper.cpp alone.

This makes me wonder:Should broad language coverage be a high-priority goal for this project? If so, onnx (via sherpa-onnx) might deserve some extra attention in the new engine architecture.

The main downside of sherpa-onnx is that sherpa-rs-sys can be a bit tricky to install. Do you have any thoughts on how to handle that in the new setup? Or maybe there's a cleaner way to package the sherpa dependencies?

Largely I love sherpa-onnx as well, and have used it in other projects. I mostly didn't pull it in due to dep issues I ran into when trying to use it in Handy. And at this point AI can more or less reimplement inference engines based on another reference. Basically it's possible to automate porting from transformers, or sherpa-onnx more or less, and at the moment that seems to be a better solution to me. Just because of all these dep nightmares. I would rather contain the dependencies to a known tree and build from that.

Broad language coverage is a goal for sure.

Perhaps the bindings to sherpa are just not very good and there's a better way to build/distribute them. I've just not taken a deep look yet. But since most everything is onnx anyway, porting is fairly straightforward and honestly prefer this way. There's probably fairly low hanging fruit in terms of automating this pipeline too..

Point at a transformers model and output:

• onnx
• mlx
• ggml
• burn
• candle
• etc....

Not just in terms of porting weights to the respective formats, but also automating the actual inference code generation too into a variety of languages. You could imagine this being done for Rust (like here), C/C++, Golang, Swift, JS/TS, etc.

And have the logits verified. I think this is reasonable enough to do, and is a direction I'm thinking a lot about. If you want to help, would love to discuss further

@zhuzhuyule for what it's worth I did the base level refactor. would love if you want to move this code into the new format. should be fairly straightforward I imagine.

The zipformer models support my native language, would love this feature to be merged!

I suggest that you use
https://crates.io/crates/sherpa-onnx

You can find doc at
https://k2-fsa.github.io/sherpa/onnx/rust-api/install.html

and examples at
https://github.com/k2-fsa/sherpa-onnx/tree/master/rust-api-examples

I think this is also probably the way forward @csukuangfj just need to test it plays nicely with the Handy CI/CD at this point. That almost certainly was one of the original blockers

Thanks for all the work you and your team do, sherpa-onnx is wonderful. It was very fun playing with it on some RK based boards recently, and using the NPU :)

For what it's worth if we add sherpa-onnx, which we probably should, it should be a new engine type. We may still choose to implement the ONNX ourselves, but being able to use the upstream would be much nicer on average. Also quite frankly more trustworthy than our implementations until we get better validation/verification of our own implementations

Update: v0.3.5 — Punct Model Fixes, GPU Accel, Log Cleanup

What changed since initial PR

1. Punct model I/O fix: Input tensors now use int32 (was incorrectly cast to int64). Output extraction handles float32 logits via argmax (model outputs [batch, seq_len, 6] probabilities, not pre-argmaxed integers).

2. GPU acceleration module (accel): set_whisper_accelerator(), set_ort_accelerator(), set_whisper_gpu_device(), and list_gpu_devices() for runtime GPU selection.

3. Log noise reduction: ONNX session tensor info, BBPE detection, punct token loading, and model file discovery logs downgraded from INFO → DEBUG.

Recommended Usage Pattern

Engines that output punctuated text (no external punct needed):

• Whisper (all variants)
• SenseVoice

Engines that output raw text without punctuation (need external punct model):

• Zipformer Transducer
• Zipformer CTC
• Paraformer
• GigaAM

Auto-detect + apply pattern:

let result = engine.transcribe(&audio, &TranscribeOptions::default())?;

// Check if output already has punctuation
let has_punct = result.text.chars().any(|c| matches!(c, 
    '，' | '。' | '？' | '！' | '；' | ',' | '.' | '?' | '!' | ';'
));

if !has_punct && !result.text.is_empty() {
    let mut punct = PunctModel::new(Path::new("models/punct-model/"))?;
    let punctuated = punct.add_punctuation(&result.text);
    // Use punctuated text
}

Notes & Caveats

• Streaming models not supported: Current ZipformerTransducerModel / ZipformerCtcModel / ParaformerModel load the full audio and run offline inference. Streaming model files (filename containing streaming) will load but may produce incorrect results — callers should use offline model variants only.
• Punct model is stateless per-call: add_punctuation() processes text in 20-token windows with 2-token overlap. For realtime preview, callers should manage their own caching/anchoring strategy.
• CT-Transformer int8 model recommended: 62MB, fast (~50ms for typical sentences). Full-precision model (266MB) gives marginally better accuracy but 3x slower.